Appl. No. 09/822,735 

Amdt. Dated January 13, 2011 

Reply to Final Office Action of October 13, 2010 

REMARKS/ARGUMENTS 

Claims 1-30 are pending in the present application. 

This Amendment is in response to the Final Office Action mailed October 13, 2010 and 
filed concurrently with a Request for Continued Examination (RCE). In the Final Office Action, 
the Examiner rejected claims 1-30 under 35 U.S.C. §103(a). Applicant has amended claims 1, 8, 
11, 18, 21, and 28. Reconsideration in light of the amendments and remarks made herein is 
respectfully requested. 

Rejection Under 35 U.S.C. § 103 

In the Final Office Action, the Examiner rejected claims 1-3, 5-7, 10-13, 20-23, 25-27, 
and 30 under 35 U.S.C. §103(a) as being unpatentable over U.S. Publication No. 2009/0164595 
Al issued to Shiigi (" Shiigi ") in view of U.S. Patent No. 6,701,493 Bl issued to Mathews et al. 
(" Mathews "); claims 4, 14, and 24 are rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Shiigi in view of Mathews and further in view of U.S. Patent No. 5,867,1 12 issued to Kost 
(" Kost "): and claims 8-9, 18-19, and 28-29 are rejected under 35 U.S.C. §103(a) as being 
unpatentable over Shiigi in view of Mathews and further in view of U.S. Publication No. 
2001/00539978 issued to Lewis et al. (" Lewis "). Applicant respectfully traverses the rejection 
and submits that the Examiner has not met the burden of establishing a prima facie case of 
obviousness. 

To establish a prima facie case of obviousness, three basic criteria must be met. First, 
there must be some suggestion or motivation, either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art, to modify the reference or to 
combine reference teachings. Second, there must be a reasonable expectation of success. 
Finally, the prior art reference (or references when combined) must teach or suggest all the claim 
limitations. MPEP §2143, p. 2100-126 to 2100-130 (8th Ed., Rev. 5, August 2006). Applicant 
respectfully submits that there is no suggestion or motivation to combine their teachings, and 
thus no prima facie case of obviousness has been established. 

Furthermore, the Supreme Court in Graham v. John Deere, 383 U.S. 1, 148 USPQ 459 
(1966), stated: "Under § 103, the scope and content of the prior art are to be determined; 
differences between the prior art and the claims at issue are to be ascertained; and the level of 
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ordinary skill in the pertinent art resolved. Against this background, the obviousness or 
nonobviousness of the subject matter is determined." MPEP 2141 . In KSR International Co. vs. 
Teleflex, Inc., 127 S.Ct. 1727 (2007) (Kennedy, J.), the Court explained that "[o]ften, it will be 
necessary for a court to look to interrelated teachings of multiple patents; the effects of demands 
known to the design community or present in the marketplace; and the background knowledge 
possessed by a person having ordinary skill in the art, all in order to determine whether there was 
an apparent reason to combine the known elements in the fashion claimed by the patent at 
issue ." The Court further required that an explicit analysis for this reason must be made. 
"[Rejections on obviousness grounds cannot be sustained by mere conclusory statements; 
instead, there must be some articulated reasoning with some rational underpinning to support the 
legal conclusion of obviousness." KSR 127 S.Ct. at 1741, quoting In re Kahn, 441 F.3d 977, 988 
(Fed. Cir. 2006). In the instant case, Applicant respectfully submits that there are significant 
differences between the cited references and the claimed invention and there is no apparent 
reason to combine the known elements in the manner as claimed, and thus no prima facie case of 
obviousness has been established. 

1. Claims 1-3, 5-7, 10-13, 20-23, 25-27, and 30: 

Shiigi discloses a method and system for creating and sending handwritten or handdrawn 
messages via mobile devices. The handwritten message is composed by the user in a graphical 
data capture area set up by the drawing editor, selecting the appropriate writing and drawing 
tools, colors, and styles as offered in the Handwriting Java Client software (Shiigi, paragraph 
[0031], lines 13-14, item 3). When the user issues a "Send" command, the Handwriting Java 
Client formats the message and sends the pixel data to the Handwriting Java Server. The 
graphical message is still in GIF format at this time (Shiigi, paragraph [0031], lines 23-26, item 
5). The Handwriting Java Server processes the graphical message data using standard base64 
encoding. This turns the data into ASCII text that can be transmitted as standard email data 
packets by the Handwriting Java Server (Shiigi, paragraph [0031], lines 27-30, item 6). The 
Handwriting Java Server creates an outgoing email message that contains the encoded 
handwritten message as a GIF attachment (Shiigi, paragraph [0031], lines 31-33, item 7). The 
Handwriting Java Server decodes the attached GIF file into pixel data and sends it to the 
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Handwriting Java Client applet running in the recipient's web browser (Shiigi, paragraph [0031], 
lines 55-57, item lib). 

Mathews discloses multiple source recording. A system accepts different types of signals 
from multiple sources and routes the signals to the appropriate devices for conversion or other 
processing so that each signal is in a common or desired format, such as the MPEG standard 
( Mathews , Abstract). Once all the selected analog and digital signals are in the same digital 
format, e.g., MPEG encoded, and are ready to be transmitted, packetizer 150 processes each 
signal stream into packets for identification and later retrieval. For example, each signal stream 
could include a header having identifying information such as the original source and format 
(e.g., type, resolution, aspect ratio) of the signal, audio content, and time ( Mathews , col. 4, lines 
46-53). 

Shiigi and Mathews , taken alone or in any combination, do not disclose or render 
obvious, at least one of: (1) an encoder to encode data in a first format from an input device into 
a string of data having a second format supported by a server having an instant message 
infrastructure, the first and second formats being different, the first format including timing 
information related to position of the input device; and (2) a packetizer coupled to the encoder to 
break the string of data into packets no larger than maximum message size allowed by the 
infrastructure, the packets having at least one packet having a header, the header identifying the 
first format; and (3) a decoder to decode a received packet encoded in the second format back 
into the data having the first format. 

First, Shiigi merely discloses attaching the graphical message as a GIF attachment 

(Shiigi, paragraph [0031], items 5 and 6), NOT an encoder to encode data in a first format from 

an input device into a string of data having a second format supported by a server having an 

infrastructure, the first and second formats being different. The pixel data representing the 

drawing remains as the GIF format. The data that are converted into the ASCII are merely data 

in the e-mail, not the graphical data representing the drawing. For ease of reference, the relevant 

excerpts are copied below. 

"5. When the user issues a "Send" command, the Handwriting Java 
Client formats the message and sends the pixel data to the 
Handwriting Java Server. The graphical message is still in GIF 
format at this time . 
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6. The Handwriting Java Server processes the graphical message 
data using standard base64 encoding. This turns the data into 
ASCII text that can be transmitted as standard email data packets 
by the Handwriting Java Server. 

7. The Handwriting Java Server creates an outgoing email message 
that contains the encoded handwritten message as a GIF 
attachment . 

8. The Handwriting Java Server sends the outgoing email message 
with GIF attachment via the SMTP (Simple Mail Transfer 
Protocol) gateway 240." (Shiigi, paragraph [0031], items 5-8. 
Emphasis added.) 

As seen from the above excerpt, Shiigi merely discloses "turn[ing] the data into ASCII 
text that can be transmitted as standard email data packets," (emphasis added) NOT the 
graphical data representing the drawing . This is because if the graphical data is converted into 
ASCII text, there would be no need to send the graphical data as GIF attachment. The fact that 
the graphical data is sent as GIF attachment indicates that the graphical data are NOT converted 
into ASCII. 

Second, Shiigi merely discloses creating an outgoing email message that contains the 
encoded handwritten message as a GIF attachment (Shiigi, paragraph [0031], lines 31-33, item 
7), NOT a packetizer coupled to the encoder to break the string of data into packets no larger 
than maximum message size allowed by the infrastructure, the packets having at least one packet 
having a header, the header identifying the first format. Attaching a GIF file to an email message 
does not break the string of data into packets. The GIF file remains intact because it is an 
attachment and not a part integral to the email message. 

In the Final Office Action, the Examiner contends that emails sent across a network are 
sent as packets and because the emails are sent successfully (no errors) to the recipient, the 
messages meet the proper message size ( Final Office Action , page 8, paragraph (b)). Applicant 
respectfully disagrees. The fact that an e-mail message is sent successfully does not mean that 
the packets have a maximum size allowed by the infrastructure. An infrastructure, such as the 
instant message infrastructure, has a different requirement than the e-mail message. 

Third, Shiigi merely discloses decoding the attached GIF file into pixel data (Shiigi, 
paragraph [0031], lines 55-57, item lib), NOT a decoder to decode a received packet encoded in 
the second format back into the data having the first format. Decoding the GIF file into pixel data 
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merely decompiles a file into pixel components. It does not convert the second format into the 
first format. 

In the Final Office Action, the Examiner contends that Shiigi teaches the receiving server 

or client decoding the ASCII text (second format) data back into the pixel data as a handwritten 

or hand-drawn image (first format), citing paragraphs [0031], parts lib, 11c, and [0037 ( Final 

Office Action , page 9, paragraph (d)]. Applicant respectfully disagrees and submits that the 

cited excerpts do not support the Examiner's argument. For ease of reference, the cited excerpts 

are copied below. 

"lib. The Handwriting Java Server decodes the attached GIF file 
into pixel data and sends it to the Handwriting Java Client applet 
running in the recipient's web browser. 

11c. The Handwriting Java Client receives the pixel data from the 
Handwriting Java Server and renders the pixel data as a 
handwritten or handdrawn image in the drawing editor/viewer ." 
(Shiigi, paragraph [0031], items lib and 11c. Emphasis added.) 

"With reference to FIG. 6, this version of the system uses the 
Handwriting Java Client along with a standard Internet email mail 
server providing email service to wireless client computers, such as 
WAP-phones and PDAs. As before, the Handwriting Java Client 
610a operates in a web browser as an installed Java applet on the 
client computer 610. The email message is formatted with the 
handwritten image converted into an attached GIF file . The Java 
applet 610a communicates with the Mail Server computer 640 
either directly or through an SMTP gateway computer 620. The 
Mail Server 640 includes a Wireless Application Protocol (WAP) 
interface which sends the email message with encapsulated GIF 
image through a Wireless Service Provider having WAP handling 
capability to the recipient. (Shiigi, paragraph [0037]. Emphasis 
added.) 

As seen from the above, Shiigi merely discloses decoding the attached GIF file into pixel 
data and rendering the pixel data in the drawing editor/viewer (Shiigi, paragraph [0031], items 
1 lb and 1 lc), NOT decoding the ASCII text into the pixel data. In fact, this excerpt reinforces 
Applicant's earlier argument that the pixel data are NOT converted into the ASCII text. 

Fourth, Shiigi merely discloses graphical data (Shiigi, paragraph [003 litems 5-6), NOT 
the first format including timing information related to position of the input device. The 
handwritten message is merely composed by the user selecting the appropriate writing and 
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drawing tools, colors, and styles (Shiigi, paragraph [0033], item 3). It therefore does not include 
the timing information related to position of the input device. To clarify this aspect of the 
invention, claims 1,8, 11, 18, 21, and 28 have been amended. 

Fifth, Matthews merely discloses each signal stream could include a header having 
identifying information such as original source and format ( Matthews , col. 4, lines 48-50), not 
identifying the first format including timing information related to position of the input device. 
The format referred to by Matthews merely includes type, resolution, and aspect ratio. These 
data are related to analog signals such as NTSC, PAL, and SECAM ( Matthews , col. 3, lines 13- 
15). None of these is related to the position of the input device. 
2. Claims 4, 14, and 24: 
Shiigi and Mathews are discussed above. 




Kost discloses software method of compressing text and graphic images for storage. 
Databases for images may be in either TIFF r EPS format. TIFF file format is used to store or 
send images as bit maps in various sizes, resolutions, or color depths ( Kost , col. 1, lines 33-39). 

Shiigi, Mathews , an d Kost , taken alone or in any combination, do not disclose or render 
obvious, at least one of: (l)-(3) above; (4) the data in the first format are scale parameters and a 
set of ink strokes that include ink color, width, and a collection of X and Y coordinates, as 
recited in claims 4, 14, and 24. 

As discussed in the 35 U.S.C. §103(a) rejection for claims 1-3, 5-7, 10-13, 20-23, 25-27, 
and 30_above, Shiigi and Mathews , alone or in combination, do not disclose or render obvious 
elements (1) and (2) as above. Accordingly, a combination of Shiigi and Mathews with any 
other references in rejecting claims 4, 14, and 24 which depend on claims 1,11, and 21, 
respectively, is improper. 

Furthermore, Kost merely discloses TIFF file format being used to store or send images 
as bit maps in various sizes, resolutions, or color depths ( Kost , col. 1, lines 33-39),not a set of ink 
strokes that include ink color, width, and a collection of X and Y coordinates. The TIFF file 
format is used to import images into computer programs ( Kost , col. 1, 32-33). Since they are 
imported into computer programs, they cannot be ink strokes. In addition, the bit maps of the 
images do not include the X and Y coordinates. 
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Moreover, the file size, color depth, canvas size, and other related characteristics, as 
disclosed in Kost are related to image data (Kost, col. 2, lines 21-24), not to ink strokes. 
3. Claims 8-9, 18-19, and 28-29: 
Shiigi and Mathews are discussed above. 




Lewis discloses a system and method for providing user-directed constraints for 
handwriting recognition. A user selects between a "default recognition" mode and a "constrained 
recognition" mode via a user interface. In the default recognition mode, a recognition engine 
utilizes predetermined default recognition parameters to decode data (e.g., handwriting and 
speech). In the constrained recognition mode, the user can select one or more of a plurality of 
recognition constraints which temporarily modify the default recognition parameters to decode 
uncharacteristic and/or special data ( Lewis , Abstract). 

Shiigi, Mathews , and Lewis , taken alone or in any combination, do not disclose or render 
obvious, at least one of: (1) - (2) above; and (3) a management layer coupled to the packetizer to 
process the packetized string of data using a processing function, the processing function being 
enabled or disabled using a configuration user interface 

As discussed in the 35 U.S.C. §103(a) rejection for claims 1-3, 5-7, 10-13, 20-23, 25-27, 
and 30_above, Shiigi does not disclose or render obvious elements (1) and (2) as 
above. Accordingly, a combination of Shiigi with any other references in rejecting claims 8, 18, 
and 28 which include elements (1) and (2), is improper. 

Furthermore, Lewis merely discloses a user to select between a default recognition and a 
constrained recognition, not a processing function being enabled or disabled using a 
configuration user interface. A user is not a processing function. Selecting between the two 
types of recognition is not the same as enabling or disabling the processing function. Selecting 
allows the user to choose one of the recognition types. It does not allow the user to enable or 
disable a processing function. 

The Examiner failed to establish a prima facie case of obviousness and failed to show 
there is teaching, suggestion, or motivation to combine the references. When applying 35 U.S.C. 
103, the following tenets of patent law must be adhered to: (A) The claimed invention must be 
considered as a whole; (B) The references must be considered as a whole and must suggest the 
desirability and thus the obviousness of making the combination; (C) The references must be 
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viewed without the benefit of impermissible hindsight vision afforded by the claimed invention; 
and (D) Reasonable expectation of success is the standard with which obviousness is determined. 
Hodosh v. Block Drug Col, Inc., 786 F.2d 1136, 1143 n.5, 229 USPQ 182, 187 n.5 (Fed. Cir. 
1986). "When determining the patentability of a claimed invention which combined two known 
elements, 'the question is whether there is something in the prior art as a whole suggest the 
desirability, and thus the obviousness, of making the combination.'" In re Beattie, 91 A F.2d 
1309, 1312 (Fed. Cir. 1992), 24 USPQ2d 1040; Lindemann Maschinenfabrik GmbH v. American 
Hoist & Derrick Co,, 730 F.2d 1452, 1462, 221 USPQ (BNA) 481, 488 (Fed. Cir. 1984). To 
defeat patentability based on obviousness, the suggestion to make the new product having the 
claimed characteristics must come from the prior art, not from the hindsight knowledge of the 
invention. Interconnect Planning Corp. v. Feil, 744 F.2d 1132, 1143, 227 USPQ (BNA) 543, 
551 (Fed. Cir. 1985). To prevent the use of hindsight based on the invention to defeat 
patentability of the invention, this court requires the Examiner to show a motivation to combine 
the references that create the case of obviousness. In other words, the Examiner must show 
reasons that a skilled artisan, confronted with the same problems as the inventor and with no 
knowledge of the claimed invention, would select the prior elements from the cited prior 
references for combination in the manner claimed. In re Roujfet, 149 F.3d 1350 (Fed. Cir. 1996), 
47 USPQ 2d (BNA) 1453. "To support the conclusion that the claimed invention is directed to 
obvious subject matter, either the references must expressly or implicitly suggest the claimed 
invention or the Examiner must present a convincing line of reasoning as to why the artisan 
would have found the claimed invention to have been obvious in light of the teachings of the 
references." Ex parte Clapp, 227 USPQ 972, 973. (Bd.Pat.App.&Inter. 1985). The mere fact 
that references can be combined or modified does not render the resultant combination obvious 
unless the prior art also suggests the desirability of the combination. In re Mills, 916 F.2d 680, 
16 USPQ2d 1430 (Fed. Cir. 1990). Furthermore, although a prior art device "may be capable of 
being modified to run the way the apparatus is claimed, there must be a suggestion or motivation 
in the reference to do so." In re Mills, 916 F.2d at 682, 16 USPQ2d at 1432; In re Fritch, 972 
F.2d 1260 (Fed. Cir. 1992), 23 USPQ2d 1780. 

Moreover, the Examiner failed to establish the factual inquires in the three-pronged test 
as required by the Graham factual inquires. There are significant differences between the cited 
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references and the claimed invention as discussed above. Furthermore, the Examiner has not 
made an explicit analysis on the apparent reason to combine the known elements in the fashion 
in the claimed invention. Accordingly, there is no apparent reason to combine the teachings of 
Shiigi, Mathews , Kost and Lewis in any combination. 

In the present invention, the cited references do not expressly or implicitly disclose any 
of the above elements. In addition, the Examiner failed to present a convincing line of reasoning 
as to why a combination of Shiigi, Mathews , Kost and Lewis is an obvious application of 
transmitting new data format under existing infrastructure, or an explicit analysis on the apparent 
reason to combine Shiigi, Mathews , Kost and Lewis in the manner as claimed. 

Therefore, Applicant believes that independent claims 1,8, 11, 18, 21, 28 and their 
respective dependent claims are distinguishable over the cited prior art references. Accordingly, 
Applicant respectfully requests the rejection under 35 U.S.C. § 103(a) be withdrawn. 

Conclusion 

Applicants respectfully request that a timely Notice of Allowance be issued in this case. 
Respectfully submitted, 

BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN LLP 

Dated: January 13, 2011 B y / THINH V. NGUYEN / 

Thinh V. Nguyen 
Reg. No. 42,034 

Tel.: (714) 557-3800 (Pacific Coast) 

1279 Oakmead Parkway 
Sunnyvale, CA 94085-4040 
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